Telecommunication service providers already know that users use more communication services than ever before in both their personal and professional lives. But to take advantage of this array of devices and drive new levels of customer service and revenue in the years ahead, the telecommunication service providers must master presence information of each user in the presence system. The status information refers to a user's availability, capability and willingness to be contacted. The presence server is a back-end component providing presence functionality. It maintains online status information for each user and web conference and also ensures that users can subscribe to information about online status (also called “presence information”) of other users.
It is assumed that a user A subscribes to view presence information of user B from a presence server who is in charge of managing a presence server of user B, then the presence server notifies user A of changed presence information when the online status of user B changes. The user A subscribing to the presence information is also called user B's watcher.
FIGS. 1A and 1B show a presence system in the prior art. As shown, a presence system 100 includes 5 presence servers (PSs) 120a-120e and 5 users (or present entities (PEs)) 110a-110e. Presence Agents (PA) 130a-130e are respectively located in the PSs 120a-120e. 
It should be appreciated that, the number of PSs, users or PAs allowed to be included in a practical presence system is not limited to 5, and a great many more devices can also be included therein.
A PA 130 collects presence information of a corresponding PE 110, and provides the presence information to one or more watchers (for example, a caller or an initiator of a communication session) of the PE 110. Further, when the PE 110 acts as a watcher of another user, the PA 130 provides the PE 110 with the received presence information of another user.
For the sake of simplicity, in FIGS. 1A and 1B, for one PE 110, only a single PA 130 is shown. However, it should be appreciated that, one PE 110 may have multiple PAs 130 of which each is in charge of a subset of all the valid subscriptions (presence information requests from watchers) for the PE 110.
An end user, for example the PE 110a, registers into the presence service by sending to its presence agent PA 130a a PUBLISH message including presence information of PE 110a (for instance, formatted as PIDF format), as shown in FIG. 1B.
Other users interested in the presence information of PE 110a, such as PEs 110b-110e, send SUBSCRIBE messages to their corresponding presence agents PAs 130b-130e respectively, which then send the SUBSCRIBE messages to the presence agent of the PE 110a, i.e., PA 130a. Therefore, these users, PEs 110b-110e, become watchers of PE 110a. 
Although 4 watchers are shown in the example of FIGS. 1A and 1B, it should be appreciated that more watchers can be involved in practical implementations, and presence agents of these watchers can be located in the same or another presence server.
When the presence information of the watched PE 110a changes, the presence server can send NOTIFY messages including the changed presence information of the PE 110a to these watchers. This process is called a SUBSCRIBE/NOTIFY process, as shown in FIG. 1A.
When desiring to change its presence status, the PE 110a will send another PUBLISH message with new presence information. Upon reception of the PUBLISH message, the presence agent PA 130a sends NOTIFY messages to presence agents of all the watchers PEs 110b-110e, i.e., PAs 130b-130e, which then send the NOTIFY messages to all the watchers PEs 110b-110e. This process is referred to a PUBLISH/NOTIFY process, as shown in FIG. 1B.
The current presence service is constructed on the basis of presence servers. But each presence server's capacity to manage users is very limited. The presence service should preferably be a real-time service, since the SUBSCRIBE/NOTIFY and PUBLISH/NOTIFY processes are delay-sensitive and end users do not tolerate delay in the application. The presence server's limited capacity limits user capability of each presence server. So, to provide the presence service, multiple presence servers are usually deployed.
However, introducing a number of presence servers also results in a new problem, that is, inter-presence server traffic is very high because most of each user's presence agents are located in different presence servers. In this example, one SUBSCRIBE/NOTIFY process will result in 1+1 messages, for instance, a SUBSCRIBE message from the presence server PS 120b to the presence server PS 120a and a NOTIFY message from the presence server PS 120a to the presence server PS 120b. Additionally, in this example, one PUBLISH/NOTIFY process will result in n NOTIFY messages (wherein n is the total number of presence servers where presence agents of watchers are located), for example, 4 NOTIFY messages from the presence server PS 120a to the presence servers PSs 120b-120e. In the case that most of messages are transferred across different servers, i.e., most of the presence agents of the user and watchers thereof are located in different presence servers, a huge traffic burden for the presence service is raised due to limitations in communication capacities, time delays and processing abilities among presence servers.